Skip to content
Catalyst Documentation

CrossCats: Solving Liquidity x Bitcoin

CrossCats is an intent-based cross-chain swap protocol built with flexibility in mind. The core idea is to allow anyone to create a request for anything provable. At launch, EVM settlements and Bitcoin transactions will be part of the provable set. Bitcoin transactions are proven using a Bitcoin SPV client and allows VM chain payments to be conditional on Bitcoin transactions.

Diagram

System Overview

CrossCats is designed for cross-chain intents. Nevertheless, the majority of logic exists on the source chain. Source Chain here refers to the chain where the order was Initiated by a solver. Remote Chain refers to the chain (or chains) where proofs are sent from. This includes asset deliveries.

Initiation (order claim)

An order is initiated by the user signing an order description. An example of an order description is My 1 Ether (Ethereum) for 3000 USD (Base). The signed order is a permit2 witness allowing the solver to submit the order to the Reactor and collect the input (1 Ether) from the user. Importantly, during this step, some collateral is collected from the solver. This ensures the solver has some skin in the game and settles the order. The collateral is paid back when the input is released to the solver.

To improve the user and solver experience, an order server sits between the user and solver and aids with order validation, propagation, and quoting.

Output Payment (to user)

The payment pathway depends on the order intent. For a VM to VM swap, the solver calls the oracle contract on the destination chain, which sends & records the token payment to the user. For VM to Bitcoin swap, the solver makes the payment described in the order. In other words, make a Bitcoin transaction that has a UTXO that matches the order description. Using an SPV client, the transaction containing the UTXO can be proven to exist.

Input Payment (to solver)

CrossCats has 3 payment release schemes to optimise the solver experience.

  1. Optimistic resolution. This assumes that the resolver delivered the payment to the user. After a dispute window (configured by the user), the payment will be released. If the order is disputed, the operation falls back to option 2.
  2. Explicit validation. At any time, orders can be proven. This requires that someone send the proof from the remote chains to the source chain. This is more costly than optimistic resolution, but may be significantly faster than optimistic resolution. Additionally, through batch verification, the cost can be reduced at a slight increase in verification speed.
  3. Underwriting. The last release scheme isn’t a payment proof scheme as much as it is a responsibility delegation scheme. If configured, an order can be bought by someone else at any point prior to the release of the input. This allows the initial solver to immediately get their capital back and hand off the payment validation to a third party.

By using these 3 schemes in conjunction with each other, solvers only have to lock liquidity for a small period of time while not sacrificing any system security. At the same time, speed, security, and cost can be rebalanced based on the specific needs of a user or chain conditions.

Bitcoin & Pseudo Solving

VM to Bitcoin swaps are relatively straight forward:

  1. User signs a message stating the input assets.
  2. Solver claims the order, inputs assets are automatically collected.
  3. Solver delivers assets.
  4. Solver is paid.

However, this flow breaks on step 2 when the user wants to go from Bitcoin to VM. (sell Bitcoin). There is no way to pull assets from a user. To solve this issue, the user becomes a pseudo solver & relies on release scheme 3. Pseudo solving works by asking solvers for short-lived Bitcoin short quotes. These orders are after validation & selection signed by the solver. The user then quickly claims the order.

Say the user wants to swap 1 Bitcoin for 50000 USDC. Using the order server, they need to collect & claim a signed order of the opposite: 50000 USDC for 1 Bitcoin. Once this order is filled, they get the input (50000 USDC) which matches their desired swap.

Important to notice, this adds a delay between when the price risk begins for the solver (issuance of signed order) to when it resolves (0-1 block confirmations of Bitcoin TXO). These values are best migrated by the following configuration:

  1. Short initiation time. Using a source chain with a low block time, the initiation time can be kept to an absolute minimum.
  2. Short proof time. The user may only have 1 or 2 Blocks to get their transaction confirmed.
  3. Designing a compatibility layer between the UI and the Order Server that only requests binding order when it is known that the user can get their Bitcoins filled.

In a future version, VM to Bitcoin swaps will upgrade to an oracle book scheme that further minimizes time between start of price risk to end of price risk.

Key differentiators

CrossCats has been designed to optimise solver integration metrics:

  • Cost of capital – Capital is only held for the duration of a swap and can be underwritten to further decrease the lock duration.
  • Speed – Minimizing settlement overhead, users receive their assets immediately, while solvers can opt in to underwriting for quick input payout.
  • Price Risk – Price Risk is minimized by letting solvers commit to swaps & providing strong order guarantees.

Locked Capital & Underwriting

CrossCats has no concept of pre-locking liquidity. Capital is only locked during the actual order flow. Additionally, Users will immediately receive their assets as deliveries are directly from the solver to the user.

Additionally, for routes supported by underwriters input assets will be available 1-5 minutes after asset delivery. This includes Bitcoin routes for users.

Price (un)Certainty

For VM to VM swaps and VM to Bitcoin swaps, the price uncertainty window is the time it takes from the moment your system commits to the order – which may be the initiate transaction – to when the order claim arrives on-chain and is successfully mined. On fast chains this is at most 2-3 seconds but may be up-to 12 seconds. Cleverly timing the commitment can reduce the uncertainty period below the block time.

For Bitcoin to VM swaps the price uncertainty window is from when the order is signed to when the user initiates the Bitcoin transaction and it gets your desired number of confirmations. This may vary from 30 seconds to 60 seconds.

CrossCats has developed a user owned pseudo escrow, that allows the Order Server to give a soft commitment to solvers that a Bitcoin UTXO will be generated. Given that a solver trusts this promise, the price uncertainty window is as low as 30 seconds or shorter.